# Релизный цикл

Мы стараемся выстроить релизный цикл, согласно статье [GitFlow в его простоте от dev до prod](https://habr.com/ru/articles/705032/).

Основные тезисы статьи:

1. Существует оптимально три стенда: для разработчиков, для ИФТ / ПСИ, продуктивный.
2. Под каждый из стендов создаётся своя ветка в системе контроля версий.
3. Разработка фич, необходимых к реализации в текущем спринте, происходит в ветке, отбранчёванной от ветки develop. После окончания разработки, содержимое ветки мёрджится обратно в develop и только в неё. Все баги, найденные по итогам этих задач, фиксятся в ветках, образованных от develop.
4. После code-freeze начинается этап отладки. Разработка текущих фич в ветке develop прекращается. Все работы по текущему спринту ведутся в ветке ift. Найденные баги фиксятся в ветках, образованных от ift. После фикса код вливается в ift, ift вливается в develop.
5. Параллельно с этапом отладки в ветке develop может вестись разработка в рамках следующего спринта.
6. В ветке master хранится только код, полностью готовый к релизу.

![Полный релизный цикл](media/gitflow.png)

## Порядок деплоя на стенд

Бывают ситуации, когда разработчику нужно проверить функциональность кода до того, как он окажется в ветке develop.
Как быть? С одной стороны, мы вливаем код в основную ветку только после код-ревью.
С другой, деплой может существенно и необратимо изменить состояние стенда, после которого невозможно будет просто откатить изменения и задеплоиться из основной ветки - например, миграции, необратимо изменяющие колонки и таблицы базы данных.

Мы следуем следующим правилам:

1. Деплой на стенд осуществляется **только** из основной ветки стенда.
2. Изменения попадают в основную ветку только после код-ревью.
3. Соответственно, на момент код-ревью код не протестирован тестировщиком.
4. Понимая это, разработчик тщательно и на совесть покрывает код модульными тестами. Это всё, что он может сделать для обеспечения качества кода на этом этапе.